Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/components/c2d/compute_engine_docker.ts`:
- Around line 1971-1974: Remove the line that assigns the decrypted resolved
value back to asset.fileObject within the persistent-storage handling code.
Instead of persisting the plaintext decrypted data (bucketId and fileName) to
the job record through asset.fileObject, keep the resolved variable local to the
current scope. The subsequent line that declares fo as a type-cast of resolved
should remain, but ensure resolved is only used locally for the current
operation, allowing uploadData to independently re-detect encrypted and
DDO-derived persistent-storage assets without storing plaintext credentials in
the persisted job data.

In `@src/components/core/compute/initialize.ts`:
- Around line 225-229: The
ensureConsumerAllowedForPersistentStorageLocalfsFileObject helper in the loop
iterating over task.algorithm and task.datasets only validates plaintext
nodePersistentStorage file objects, causing encrypted file objects and
documentId/serviceId persistent-storage references to skip ACL validation at
initialize time. Before calling
ensureConsumerAllowedForPersistentStorageLocalfsFileObject, resolve the
effective file object for each elem by applying the same decrypt and DDO
resolution step that the Docker path uses later, then pass the resolved file
object to the ACL helper instead of the raw elem.fileObject so that denied
consumers fail with the expected 403 error during initialization.

In `@src/components/core/compute/startCompute.ts`:
- Around line 234-238: The ACL preflight validation in the loop iterating
through task.algorithm and task.datasets only checks raw elem.fileObject, which
bypasses encrypted file objects and persistent-storage references using
documentId or serviceId. Resolve and decrypt file objects first before passing
them to ensureConsumerAllowedForPersistentStorageLocalfsFileObject, or extend
that helper function to handle encrypted and DDO-resolved persistent-storage
inputs directly. Apply this fix to both loop occurrences (the one checking
task.algorithm and task.datasets, and the second loop at lines 782-786) to
ensure all compute file-object representations are validated before jobs are
accepted or funds are locked.

In `@src/components/core/handler/ddoHandler.ts`:
- Around line 779-780: Remove the two console.log debug statements at lines
779-780 in the ddoHandler.ts file that log the validation object directly and as
stringified JSON. These calls bypass the module logger and pollute stdout.
Replace them with a single call to CORE_LOGGER (imported from
src/utils/logging/common.ts) at an appropriate log level (such as debug) with a
meaningful message and the validation data, or remove them entirely if they are
no longer needed for debugging purposes.

In `@src/components/core/handler/downloadHandler.ts`:
- Around line 68-72: The type comparison in the conditional block starting with
`(task.fileObject as { type?: string })?.type ===
FileObjectType.NODE_PERSISTENT_STORAGE` is case-sensitive, but
Storage.getStorageClass accepts storage types case-insensitively. To prevent
case variations from bypassing the consumerAddress guard, normalize the case of
the storage type string before comparing it to
FileObjectType.NODE_PERSISTENT_STORAGE. Convert the type property to a
consistent case (such as lowercase or uppercase) before the equality check to
ensure the 403 guard is enforced regardless of the input casing.

In `@src/components/core/handler/fileInfoHandler.ts`:
- Line 30: The file type check at line 30 in the fileInfoHandler function only
validates the embedded file.type property directly without also verifying it
against the normalized command.type, which allows requests to bypass
restrictions by embedding FILE_OBJECT_TYPE.NODE_PERSISTENT_STORAGE while setting
an allowed top-level type. To fix this, ensure the persistent storage access
check validates both the command type (normalized to handle casing variants) and
the embedded file type together, similar to how formatMetadata handles
normalization. Apply the same validation logic to the additional check at lines
77-82 to prevent casing variants from bypassing the storage routing gates.

In `@src/components/persistentStorage/PersistentStorageFactory.ts`:
- Around line 200-218: The consumerAddress parameter in both getFileInfo and
getReadableStream abstract methods is currently optional, which allows callers
to bypass ACL enforcement by simply omitting this parameter. Make
consumerAddress a required parameter by removing the optional marker (?) from
its definition in both method signatures, or alternatively split these methods
into separate implementations where one provides explicit trusted internal
access without ACL checks and another requires consumerAddress as a mandatory
parameter for ACL-enforced access.

In `@src/test/integration/persistentStorage.test.ts`:
- Around line 496-505: The try-catch block in the
intruderStorage.getReadableStream() test catches all exceptions and treats any
error as an access denial, which can mask unexpected errors. Instead of a bare
catch block, catch the exception and verify it is specifically an access denial
error (check the error type or message for access control related details). Only
set denied to true if the caught error is the expected access denial error, and
fail or re-throw if it is an unexpected error type.
- Around line 404-412: The try-catch block in the test is catching all
exceptions without validating the specific error type or message, which could
mask unrelated failures as false positives. Instead of setting denied to true
for any caught exception, verify that the specific error thrown by
getFileChecksum indicates an access denial error by checking the error message
or error type/code (such as checking if the error contains specific text like
"access denied" or "forbidden" or if it matches a specific error code). Use
expect assertions to validate the error details rather than just relying on the
catch block to confirm the denial occurred.

---

Outside diff comments:
In `@src/components/core/compute/utils.ts`:
- Around line 51-79: The current catch block indiscriminately converts all
errors into empty checksums, but persistent-storage authorization/config errors
should propagate as structured errors to preserve HTTP status semantics. Modify
the error handling to distinguish between persistent-storage related errors (the
error thrown for missing consumerAddress when file type is
nodePersistentStorage, and authorization errors from the
fetchSpecificFileMetadata call) and other errors. Let persistent-storage errors
re-throw as typed/structured errors so handlers can report proper HTTP status
codes, while only catching and returning empty checksums for ordinary checksum
lookup failures that don't involve storage authorization or configuration
issues.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/components/c2d/compute_engine_docker.ts`:
- Around line 1965-1969: The type check at line 1967 comparing resolved.type
against the literal string 'nodePersistentStorage' does not normalize the type
value before comparison, which means persistent-storage files with different
casing variants will not match and will incorrectly fall into the normal asset
provisioning path instead of being bind mounted. Normalize the resolved.type
value by converting it to lowercase (or a consistent case) before comparing it
against a normalized persistent storage type string. Apply this same
normalization fix to all other persistent-storage type checks in the file,
including the skip branches near line 1967 and the additional occurrences
mentioned in the "Also applies to" comment at lines 2939-2950 and 2988-2990.

In `@src/components/core/compute/utils.ts`:
- Around line 49-55: The type check in the guard condition is case-sensitive,
comparing against 'nodePersistentStorage', but storage resolution is
case-insensitive. This means mixed-case type values like 'NodePersistentStorage'
can bypass the guard and skip the intended error. Normalize the type value to
lowercase before performing the comparison in the conditional check to ensure
all case variations of persistent storage types are properly caught and throw
the required error for missing consumerAddress.

In `@src/components/core/handler/fileInfoHandler.ts`:
- Around line 37-47: The current implementation returns valid placeholder
metadata for persistent-storage files in the isPersistentStorageType check,
which still exposes these files through fileInfo when resolved via the
did/serviceId path. Remove this placeholder return statement and instead modify
the did/serviceId resolution branch to return a 403 Forbidden status code when
formatMetadata(...) returns null (indicating persistent storage), preventing the
placeholder metadata from being added to the response at all.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/test/unit/download.test.ts`:
- Around line 218-231: The test currently only checks exact-case
nodePersistentStorage, but the storage resolution is case-insensitive, allowing
mixed-case variants like NodePersistentStorage to bypass the denial. Add a new
test case in the test suite that verifies handleDownloadUrlCommand properly
denies downloads for mixed-case file object types (such as
NodePersistentStorage), and update the handleDownloadUrlCommand handler itself
to perform case-insensitive type comparison when checking for the persistent
storage type to ensure all case variants are caught by the denial logic.

---

Outside diff comments:
In `@src/components/core/compute/initialize.ts`:
- Around line 106-112: The ACL preflight validation that calls
ensureConsumerAllowedForPersistentStorageLocalfsFileObject() currently executes
at line 228, after the getAlgoChecksums() call at line 106. For
persistent-storage algorithms, this allows unauthorized consumers to fail during
checksum retrieval with a generic error instead of receiving the explicit ACL
denial response. Move the entire ACL preflight loop that includes the
ensureConsumerAllowedForPersistentStorageLocalfsFileObject() check to execute
before the getAlgoChecksums() function call, ensuring authorization validation
happens first and returns the intended denial response before any checksum
computation work begins.

In `@src/components/core/compute/startCompute.ts`:
- Around line 211-217: The getAlgoChecksums function is currently called before
the ACL preflight validation loop, which causes unauthorized consumers to
receive a generic 500 error instead of an explicit ACL denial response when
dealing with persistent-storage algorithms. Reorder the code in the startCompute
flow so that the ACL preflight check validating access to task.algorithm and
task.datasets executes before the getAlgoChecksums call, ensuring authorization
is confirmed before attempting checksum retrieval.

In `@src/components/httpRoutes/fileInfo.ts`:
- Around line 36-58: The consumerAddress variable is currently being read
directly from req.body without verification, which allows callers to spoof an
allowlisted address and gain unauthorized metadata access. Remove the line that
extracts consumerAddress from req.body and instead derive it from the verified
req.caller property. Update the fileInfoTask object construction (both the if
and else branches) to use the verified consumerAddress derived from req.caller
rather than the unverified body value before passing it to FileInfoHandler.

---

Nitpick comments:
In `@src/components/c2d/compute_engine_docker.ts`:
- Around line 3403-3405: The resolveComputeFileObject function is currently
exported from compute_engine_docker.ts but is used by multiple modules including
compute pre-checks and Docker provisioning, creating an inappropriate dependency
on the Docker engine module from core compute code. Move this function without
any changes from compute_engine_docker.ts into a new or existing shared compute
utility module, then update all import statements in files that currently import
resolveComputeFileObject from compute_engine_docker.ts to instead import it from
the shared utility module.

In `@src/components/persistentStorage/PersistentStorageLocalFS.ts`:
- Around line 263-277: The getFileInfo method returns st.mtimeMs directly as a
float value for lastModified, but the listFiles method uses
Math.floor(st.mtimeMs) to return an integer. To maintain consistency across both
methods, wrap st.mtimeMs with Math.floor() in the return statement of
getFileInfo so that lastModified is always returned as a truncated integer
value, matching the behavior in listFiles.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@src/components/persistentStorage/PersistentStorageLocalFS.ts`:
- Around line 257-260: The consumerAddress parameter is declared as required in
the abstract interface, but the implementation includes an unnecessary if
(consumerAddress) conditional check and a misleading comment suggesting the
checksum can be obtained without it. Remove the conditional wrapper around the
this.assertConsumerAllowedForBucket(consumerAddress, bucketId) call to make it
execute unconditionally, and update or remove the misleading comment to
accurately reflect that consumerAddress is a required parameter. This aligns the
implementation with the required parameter contract defined in the abstract
interface.